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ABSTRACT 


The U.S. Army uses a Unit Readiness Index to track the combat readiness of 
systems. The Unit Readiness Index relies on the accuracy of automated and manual 
testing of the hardware and related software of the Line Replaceable Units (LRUs) that 
comprise the system. These tests are based on a GO/NOGO scenario. When an LRU 
fails, vehicle commanders, and commanders up the chain of command, can override this 
and continue with a mission. Overriding the NOGO recommendations produces a false 
combat readiness status for the unit, and creates a number of problems related to unit 
combat decisions as well as logistical support. This thesis introduces a new process for 
more effectively tracking combat readiness. It outlines some of the problems associated 
with the current GO/NOGO scenario and examines the current tests, artifacts and data 
available from the current process. It proposes an additional Report process and shows 
how this new process will eliminate the readiness tracking problems associated with the 
GO/NOGO scenario. It also presents the design of a Vehicle Database and Master Fault 
Database to support the proposed process, and presents several sample reports generated 
from this Master Fault Database. 
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I. INTRODUCTION 

A. DESCRIPTION OF PROBLEM 

The Army uses the Unit Readiness Index (URI), described in detail in Chapter II, 
to evaluate combat readiness. To make this thesis manageable, we shall focus our 
discussion on a single platform, the Abrams M1A2 Main Battle Tank, although the URI 
applies across all platforms. 

For the Abrams M1A2 Main Battle Tank, the hardware portion of each Line 
Replaceable Unit (LRU) undergoes a continuous automated self-test (ST). When 
hardware fails, crewmembers normally perform an intrusive Built-In Test (BIT). 
Continued failure results in having the hardware undergo an even more rigorous Fault 
Isolation Test (FIT). The software for all three sets of tests resides in each LRU. 

The Army uses the phrase “hardware” to describe an LRU; in reality, an LRU 
consists of a hardware component and a corresponding software component. If an LRU 
fails, no differentiation is made between the two components. A failed LRU affects the 
readiness of the vehicle, which in turn affects the readiness of the vehicle’s unit. A tank 
out of commission affects readiness up the chain of command through the Division level. 
Figure 1 depicts a typical tank command structure. Figure 2 shows the LRUs contained in 
the M1A2 (Ronald Siegel 1999). Not all LRUs have software resident within them; 
Figure 3 depicts the architecture for the LRU components in a tank that contain software 
(GDLSM1A2 SDP 2003). 

Test results of an LRU are classified as either GO or NOGO. When it is NOGO, 
the LRU must be replaced, or the entire vehicle is considered NOGO. A potential major 
problem is created when test results are overridden and failures are not addressed. A 
vehicle’s commander can override the test results, which typically occurs when the 
failure is examined and determined to be in a non-mission critical area. Reported failures 
can also be overridden up the chain of command at the Company or Battalion level. A 
vehicle declared out of commission affects the operational readiness of both the unit and 
the commands of which the unit is a member. 
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Figure 1 Tank Command Structure 


M1A2 LRU Architecture 
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Figure 2 M1A2 LRU Architecture 
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Figure 3 M1A2 Software Architecture 


There are many good reasons for overriding failures. For example, during several 
conversations with former Tankers, they all stated they would not want to take the time to 
enter information on failures while they were in Combat Mode. Overriding a failure 
should only delay responding to the failed test. Overriding a readiness rating on a piece 
of hardware, for any reason, has numerous ramifications, as described in the following 
paragraphs: 

Invalid Test. If the same test is failing across multiple units, the test may be bad. 
Not reporting it will increase the likelihood it will never get corrected. Furthermore, 
ignoring a NOGO because the crew thinks the test may be reporting an invalid failure 
may result in the tank crew failing to identify a real problem. This might occur when the 
crew learns the same test is failing in other vehicles. While it may be invalid in some 
vehicles, it might indeed be valid in others. 

Common Problem. If the same test is failing across multiple units and the test is 
not bad, then a common problem exists and needs to be addressed. The bad 
hardware/software needs to be resolved as soon as possible. 
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Number of Failed LRUs. If only a few LRU failures are reported, the problem 
may not get resolved. When there are large numbers of failures for the same test, the 
reason behind the failures needs to be quickly determined and resolved. Overriding 
failures can mask the magnitude of the problem. Resources may be directed toward other 
more widely reported problems instead of the larger ‘hidden’ one. 

Undefined Actual Operational Readiness. If the Tank Commander (TC) 
overrides the test, or those above the TC in the chain of command override the failure 
report, a vehicle may be rated as combat ready when a potentially serious problem is 
aboard. The Tank-Automotive Armament Command (TACOM) Commanding General, 
MG N. Ross Thompson III gave a briefing discussing the state of readiness in vehicles 
entering Iraq to the Chief, Logistics, Coalition Forces Land Component Command, MG 
Claude V. Christianson. During this briefing, MG Thompson estimated that “FORSCOM 
IG unit maintenance brief findings state reported readiness rates exceeding 90% while 
actual readiness [was] at less than 50%”(MG Thompson 2003). 

Logistics. The supply of spares on hand might need to be increased, but problems 
aren’t being identified in the supply chain. When there are multiple vehicles requiring a 
replacement LRU and the problem is not recognized because the overridden failures are 
not reported, there won’t be enough spares to satisfy this need. 

Additional Failures. Continuously overlooking a failure may impact or mask 
other problems developing in the same piece of hardware. This may cause the developing 
problem to be overlooked, thus creating a potential hazardous situation and jeopardizing 
the actual readiness of the unit. 

Trend Analysis. Failed LRUs should undergo trend analysis to determine if 
failures are occurring after a period of time or usage, or if multiple problems are 
developing in the same area. Not reporting failures prevents this type of analysis. Trend 
analysis for software issues can indicate whether the software is too complicated or has 
had too many modifications applied. This information is important to the group 
maintaining the software and is used for decisions such as whether the software should be 
repaired or needs to be replaced. 
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B. PROPOSED SOLUTION 

Commanders will continue to have the capability to override test results during 
combat situations. This capability will continue to be available up the chain of command. 
However, failures cannot be overlooked; the ramifications are too serious. A simple 
solution is to modify the test software so that, when not in combat mode, each failure 
requires a comment. Test results for all failures, with accompanied comments, will be 
stored in a vehicle database. At a later time, while undergoing routine preventive 
maintenance, test results will be included as part of the hardware readiness report 
submitted by the maintenance facility. They will also be merged into a Master Fault 
database residing at each level of command above the vehicle, along with any comments 
or explanations for overriding vehicle(s) readiness status by the higher command. 

This information will be used to perform trend analysis at the vehicle’s major 
command and provide commanders with an accurate understanding of the actual 
readiness of the vehicles under that command. 

C. THESIS ORGANIZATION 

This chapter gives a brief description of the problem, providing an accurate 
picture of the operational readiness of vehicles within a major command, and then offers 
a solution to this problem. Chapter II presents an analysis of the current Unit Readiness 
Index tracking process. It explains the tests that are used to determine the readiness of a 
vehicle and gives examples of reports currently generated from this data. The chapter 
also performs a high-level use case analysis of the proposed enhancement offered in 
Chapter I. 

Chapter III contains elements of a design for a Master Fault Database, which is 
part of the proposed problem resolution. The design includes Object diagram; sample 
database layouts; and closes with several sample reports generated using the database. 
Chapter IV is the thesis’ conclusion. It discusses the value added by the proposed 
enhancement as well as challenges and opportunities associated with the implementation 
of this solution. 
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II. ANALYSIS OF THE UNIT READINESS INDEX TRACKING 

PROCESS 

A. UNIT READINESS INDEX 

The Army currently uses a Unit Readiness Index to determine the state of 
readiness of units of all sizes. Units may vary from a squad of tanks, for example, all the 
way to a brigade or higher. Information is extracted from the “Army’s unit status report 
(USR), which is a part of the Global Status of Resources and Training System 
(GSORTS). GSORTS is an internal management tool for use by the Chairman, Joint 
Chiefs of Staff (CJCS), the Joint Staff, the Services, the unified commands, and the 
combat support agencies. GSORTS is the single automated reporting system within the 
Department of Defense that is the central registry of all operational units of the U.S. 
Armed Forces and certain foreign organizations. As a unit readiness system, GSORTS 
indicates the level of selected resources and training required to undertake the mission(s) 
for which a unit was organized or designed. GSORTS provides this information on 
measured units at a specific point in time.” (U.S. Army 2001) 

Three resource areas are examined: personnel, including the personnel’s training 
status, equipment-on-hand, and equipment serviceability, using the criteria provided in 
regulation 220-1. Each unit commander also determines an overall unit status level by 
considering the status of the unit’s measured resource areas and training status and by 
applying his professional judgment. This information, including remarks submitted to 
clarify category levels, is gathered together to create a Mission Accomplishment Estimate 
(MAE). The MAE is the reporting unit commander’s subjective assessment of the unit’s 
ability to execute that portion of the wartime mission that it would be expected to 
perform if alerted/committed within 72 hours of the “as-of” date of the report. The 
commander expresses this estimate in terms of the percentage of the wartime mission that 
the unit could accomplish if it were alerted/committed. 

The information is gathered via the Personal Computer/Army Status of Resources 
and Training System (PC/ASORTS), whenever possible, or is submitted via DA Form 
2715. Reports are submitted as of the 15th day of each month and must be received 
within 96 hours of the due date. 


7 



The “National Security and Military Strategies require the Army to provide forces 
capable of world-wide operations across the full spectrum of conflict, from small 
peacetime engagements to major regional wars. In order to meet these readiness 
challenges, we must resource the Army with quality people, lead by competent and 
confident leaders, and armed with reliable, modem equipment.” (DAVID L GRANGE, 
MG 1997) Thus, we need to know the following: 

• How can we determine what our state of readiness actually is? 

• If the state is too low, what specified minimal level should that state be 
raised to? 

• What will it take to raise it to that level? 

• How accurate is this assessment? 

Units determine and report in the Unit Status Report (USR) an equipment 
serviceability (ES) level (R-level) (See Table 1, extracted from Table 6-1 in AR220-1.). 
The unit’s R-level indicates how well the unit is maintaining its on-hand equipment. 


Level 

Equipment other than aircraft 

Aircraft 

1 

100-90% 

100-75% 

2 

89-70% 

74-60% 

3 

69-60% 

59-50% 

4 

Less than 60% 

Less than 50% 


Table 1 Level for percentage of equipment fully mission capable 


Once a measurement of the overall state of equipment is determined, decisions 
can be made as to what actions should be taken to raise a substandard level of readiness 
to an acceptable level. For example, a cost tradeoff analysis may be made to determine if 
the hardware should be improved, if software modifications should be made, or if some 
combination of the two must be performed. 
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There are three levels of testing performed on the M1A2. These are described in 
Table 2 and are extracted from the Fault Management volume of the M1A2 
System/Segment Design Document (GDLS S/SDD 2003). 


Self-Test (ST) 

Self-Test is the first level of embedded diagnostics within the 

M1A2 tank. ST reports faults to the crew during all modes of 

operation. Self-Test data runs in the background of each 

LRU. ST runs upon power-up and performs a health check 

on the system without affecting tank functions. 

Built-In-Test (BIT) 

Built-In-Test is the second level of embedded diagnostics. 

BIT is an intrusive test of the system health status. 

Fault-Isolation-Test (FIT) 

Fault Isolation Test is the third level of embedded 

diagnostics. FIT utilizes the results from Self-Test and Built- 

In-Test to reduce ambiguity groups within the system. The 

corresponding ST and BIT results are incorporated into 

variables. These variables make up several hundred Boolean 

equations to isolate faulty units and generate troubleshooting 

procedure (TP) numbers. 


Table 2 Levels of Software Testing 


1. Self-Test 

Self-Test (ST) runs continuously in all modes, and is the first level of diagnostics 
to detect a failure. Upon detection of a failure, a NOGO message is displayed on the 
Commander’s Integrated Display (CID), with a backup copy of the message displayed on 
the Gunner’s Control and Display Panel (GCDP). The message identifies the LRU 
containing the failure, i.e., if a failure is detected in the DID LRU, the NOGO displayed 
is for that LRU. 
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2. Built-In-Test 

Once ST detects a failure, the tank crew is expected to perform further diagnostic 
testing using Built-in Test. Figure 4 is a screen shot showing the status of the LRUs in the 
M1A2, following BIT. 

This testing can only be performed while in Diagnostics mode - if the vehicle is 
in Combat or some other mode, testing must be delayed (due to the intrusive level of the 
BIT testing.) Once in Diagnostics mode, BIT is executed to confirm the failure. BIT is 
more stringent; for an LRU, according to paragraph 1.1.3 of the S/SDD (GDLS S/SDD 
2003); 

“The BIT diagnostics augmented by Manual Test Procedure (MTP), shall meet 

the following requirements: 

a. Ninety-five percent probability of detecting all on-board system-level 
faults. 

b. Zero ambiguity in fault isolation of a system. 

c. Ninety-percent probabilities of fault isolating to a LRU or Line 
Replaceable Module (LRM). 

d. Less than TEN PERCENT BIT false alarm rate. 

e. BIT failure shall not degrade performance of the prime system (i.e., 
BIT failure is transparent to systems operation). 

f. BIT shall have self-test capability.” 

When ST or BIT detects fault conditions that cannot be resolved or explained, the 
problem, including a description of the extent of the failure and a recommended severity 
level, is submitted to organizational maintenance. 
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Figure 4 BIT Vehicle Test Results 


3. Fault-Isolation-Test 

After verifying the problem is reproducible (by re-running BIT), maintenance 
personnel will run the Fault-Isolation-Test using a Direct Support Electrical System Test 
Set (DSESTS), shown on the left in Figure 5 below. 



Figure 5 DSESTS, connected to a DID 


If FIT also fails, the maintenance unit will replace the faulty Line Replaceable 

Unit (LRU) hardware. When the maintenance unit determines the problem exists in 
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multiple LRUs they will declare that an LRU ambiguity group exists. (If the failure 
cannot be isolated using these tests, the maintenance personnel will perform manual 
testing to try to identify the problem.) 

Unit maintenance will perform further testing using the Intermediate Forward 
Test Equipment/Commercial Equivalent Equipment (IFTE/CEE). An LRU typically 
consists of one or more Shop-Replaceable Units (SRUs). An example of an SRU would 
be a circuit board contained in an LRU (See Figure 6, below) or the 1553B cable 
connecting the LRU to the network. The IFTE/CEE tests to the sub-SRU level; i.e., it 
examines the components on a circuit board. Figure 7 lists actual LRUs and embedded 
electronic module SRUs for an M1A2. 
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Figure 6 Driver’s Integrated Display - Internal View 
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Figure 7 M1A2 LRUs and Electronic Module SRUs 
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When a failure occurs and a FIT warning is displayed, the Tank Commander or 
Maintenance crewmember can display the corresponding troubleshooting procedure (TP) 
number. Figure 8 is a screen shot, showing TP #s generated during FIT. Each TP 
number is unique and uses the results from Self-Test and Built-In-Test to reduce 
ambiguity groups within the system. The corresponding ST and BIT results are 
incorporated into variables. These variables make up several hundred Boolean equations 
to isolate faulty units and generate troubleshooting procedure (TP) numbers. For 
example, 

“TP# 302 will be generated if the [remote power control] RPC on the [Hull Power 
Distribution Unit] HPDU that supplies power to DID is TRIPPED or NO-LOAD. At the 
same time, 1553 data bus communication must be valid to DID. TP# 302 is represented 
by the following equation. 

lv = ( AM_HPDU_RPC_8_TRIP_DID or AN_HPDU_RPC_8_NO_LOAD_DID 
) and IU_DATA_BUS_A_DID and IV_DATA_BUS_B_DID” 

A detailed set of formulae used for determining these troubleshooting procedures 
are contained in the M1A2 System/Segment Design Document. (GDLS S/SDD 2003) 



Figure 8 Sample FIT TP #s 
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B. EXISTING REPORTS 

Data is generated at the unit level and gathered by the Army Material Status 
System where it is stored in the Readiness Integrated Data Base (RIDB). The RIDB is 
used for analysis of readiness data generated from unit status, aircraft, missile, and 
ground equipment reporting. Two reports are issued using data within the RIDB: 
Operational Readiness Summary Reports, which show the Operational Readiness status 
within the Major Command at the date the report is generated, and the Equipment 
Downtime Analyzer Report, which shows more detailed information for the date the 
report is generated. Both reports only go to a vehicle level of detail. Failure information 
on LRUs, while reported by the Unit, is not covered by either of the two reports. 

1. Operational Readiness Summary Reports 

Figure 9 shows four actual examples of the summary reports of the operational 
readiness for one of the fielded M1A2 Divisions. They explain why the Operational 
Readiness goal of 90% wasn’t met, and what actions are being taken to resolve it. Each 
report reviews the Fully Mission Capable (FMC) Index for the reporting period. There 
are several issues to highlight: 

The FMC Index is an average value for the appropriate monthly period. It does 
not address figures for any specific day. The daily Index may be much higher (or lower) 
than the monthly value. Moreover, units being deployed are not included in the reports 
and the reports consistently recommend the same near-term fixes. 
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2. The Equipment Downtime Analyzer Reports 

The Equipment Downtime Analyzer (EDA) Report “provides insight through 
comparison of different organizations and end item fleets. It can help answer questions 
such as: 

Is this fleet’s readiness problem the result of high repair time, a high 
failure rate, or both? 

Is an organization’s long repair time driven by organizational or support 
level repairs? 

How much does parts wait time contribute to repair time? 

What parts are contributing the most to lost readiness? 

If inventory is improved, what will be the effect on equipment 
readiness?”(CASCOM) 

The EDA report also covers a monthly period, but uses a calendar month 
timeframe, rather than the URI timeframe of the 16 th of one month to the 15 th of the next. 
It provides more detail than the RIDB summary, allowing the user to “drill down” within 
the report to determine just how long a specific vehicle was considered Non Mission 
Capable (NMC) and why. However, like the Operational Readiness Summary Report the 
EDA report only goes to the vehicle level, Figure 10 is a sample top-level report. 

The Major Command has the capability of examining logistic reports for spare 
parts ordered and generating a report of LRUs that are failing within the command. 
However, occasionally the wrong part is ordered and a second LRU is needed to correct 
the problem. This means that looking at logistical reports of parts ordered does not 
necessarily provide an accurate picture of LRU failure trends. 
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Figure 10 EDA Report for 4ID - 01/04 - 02/04 
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III. PROPOSED ENHANCED PROCESS 


The GO/NOGO approach is well known, has been in use for a long time, and will 
continue to be used. The information generated from the reports in Section B of Chapter 
II above, tracks to the vehicle level. This needs to be enhanced to be more proactive in 
addressing failures. 

A. USE CASE ANALYSIS 

Use Cases are valuable because they allow a process to be broken down into an 
easily understood set of diagrams. Use Case methodology will be used here to explain the 
proposed process. “A use case has two parts: the use case diagram and the use case itself. 
The diagram provides an overview of which interactions will be important, and the use 
case’s text details the requirements.” (Daryl Kulak and Eamonn Guiney 2002) 

Use cases show the interaction between the system and external entities, called 
Actors. Figure 11 is the system level context diagram for the Master Fault Database. For 
the proposed process, there is one system called the Master Fault Database, which 
interacts with several Actors. The Actors are as follows: 

• The Vehicle Database, from which the majority of the raw data is 
extracted. 

• Users at the vehicle’s maintenance facility who will close out the fault 
record in the Database once the FRU has been repaired/replaced and the 
vehicle declared Mission Capable. (This assumes there is only one fault. 
When multiple faults occur, as each FRU becomes operational within the 
vehicle, the fault will be considered to be resolved.) 

• Users at some level between the vehicle and the Major Command. These 
actors will be adding additional comments such as why the vehicle’s 
Readiness Report is overridden. 

• Users at the Major Command that will be using the raw data to generate 
reports used in trend analysis and for logistics. 
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Vehicle 
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Command 


Major 
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Figure 11 System Level Context Use Case - Master Fault Database 


There are four use cases associated with this system. Because the number of 
actors interfacing with the system is small and straightforward, the use case diagrams are 
not included. Instead, the use case descriptions, in table format, are provided as stand¬ 
alone entities. 

1. Fault Data Collection Use Case 

This use case describes the process of recognizing a fault and collecting related 
data. It also describes uploading accumulated data to the Master Fault Database and 
resetting the Vehicle Database to free up precious space on the vehicle. 


Use Case Name: Fault Data Collection 

Actors: Tank Crew, Unit Maintenance Crew, Vehicle Database 

Summary: When a fault has been detected in a vehicle, related data is collected. During 
maintenance, after verifying the fault is repeatable, the fault data is transferred to the 
Master Fault Database and the Vehicle Database is reset. 

Basic Course of Events: 

1. Vehicle performs self-test and detects a fault. 

2. Vehicle notifies Tank Crew of the failure and stores failure information in the 
Vehicle Database. 
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3. Tank Crew runs BIT to verify the fault exists. If necessary, Tank Crew adds 
comments to the Vehicle Database. 

4. Vehicle updates the Vehicle Database. 

5. Maintenance Crew will re-run BIT. If the fault is repeatable, they will run FIT 
and, if necessary, add comments to the Vehicle Database. 

6. Vehicle will update the Vehicle Database with new comments and add TP # data. 

7. Maintenance Crew transfers data from the Vehicle Database to the Master Fault 
Database. After receiving an acknowledgement from the Master Fault Database, 
the vehicle will reset the Vehicle Database. 

Alternative Paths: N/A 

Exception Paths: In step 5, if the problem is non-repeatable, the fault record will be 
deleted from the Vehicle Database 

Trigger: A fault is recognized 

Assumptions: The vehicle is not in Combat mode. 

Preconditions: Vehicle is running 

Postconditions: New records added to the Master Fault Database; Vehicle Database has 
been reset 

Date: 20-Dec-04 

Table 3 Fault Data Collection Use Case 

2. Override Readiness Index Use Case 

This use case describes when a User in the Senior Command, above the Unit 
level, has overridden the Unit Readiness status of a vehicle. That User must also add a 
comment to the appropriate record in the Master Fault Database. Note that even though 
the vehicle is considered Mission Capable, the fault will continue to exist in the Master 
Fault Database until someone in the Unit Maintenance group corrects the problem. Only 
then will the fault be closed. 
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Use Case Name: Override Readiness Index 
Actors: Senior Command Member 

Summary: When a member of the Senior Command wants to override the vehicle’s 
Operational Readiness status, information identifying the User, together with a comment 
explaining the action taken, must be added to the Master Fault Database. 

Basic Course of Events: 

1. The User logs on to the Master Fault Database. 

2. The system displays a list of options to the User. 

3. The User requests access to a vehicle’s record. 

4. The system displays the appropriate record and prompts for additional 
information. 

5. The User enters requested information, including a comment on the change in 
Operational Readiness status. 

6. The System updates the record within the Master Fault Database. 

7. The User logs out of the database. 

Alternative Paths: In step 7, if the user wants to modify another vehicle’s record, steps 3 
through 6 are repeated. 

Exception Paths: In step 3, if the User enters an invalid vehicle identifier, the System 
displays an error message and re-prompts for the vehicle identification. The User may 
also go directly to step 7. 

Trigger: The User requests to update a record in the Master Fault Database 

Assumptions: Someone in the vehicle’s chain of command has decided the vehicle is 
Mission Capable 

Preconditions: A Unit Readiness Report has been received indication the vehicle is NMC. 
Postconditions: 
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Table 4 Override Readiness Index Use Case 


3. Report Generator Use Case 

This use case describes when a User in the Major Command requests a new 
report. Reports are usually run on a scheduled basis but may also be run on an exception 
basis. Moreover, reports are typically run at the Major Command but may be run by 
anyone within the chain of command. E.g., someone in Unit Maintenance might request 
a report if there is a concern about similar problems with other vehicles. 


Use Case Name: Report Generator 

Actors: Authorized User within the vehicles chain of command (up to the Major 
Command level) 

Summary: A User requests a report be generated. The report is generated using data from 
the Master Fault Database 

Basic Course of Events: 

1. User logs onto the Master Fault Database and requests a report. 

2. System displays available reports for that specific User 

3. User chooses a report. 

4. System processes the data and generates the report. 

5. User logs out of the database 

Alternative Paths: In step 5, when additional reports are requested, steps 2 through 4 are 
repeated. 

Exception Paths: In step 3, if the User is not authorized to request a specific report, step 2 
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is repeated. The User may choose to go to step 5 if desired. 

Trigger: N/A 

Assumptions: User has access to the desired reports. 

Preconditions: User has logged onto the Master Fault Database 
Postconditions: Desired reports are generated 
Date: 20-Dec-04 

Table 5 Report Generator Use Case 

4. Close Vehicle Fault Use Case 

This use case describes the steps taken when a member of the vehicle’s unit 
maintenance group closes a fault. Note that only someone from the Unit Maintenance 
activity has authority to close a record. That will prevent accidental closings, which in 
turn would cause invalid trend analysis. A fault may be closed without changing the 
status of the vehicle’s Operation Readiness. This may occur if there is more than one 
fault for an LRU, or if the vehicle is considered NMC because multiple LRUs have 
failed. The vehicle will be considered Mission Capable when all faults have been closed 
for that vehicle. 


Use Case Name: Close Vehicle Fault 
Actors: Unit Maintenance personnel 

Summary: Someone from Unit Maintenance requests a vehicle’s fault record in the 
Master Fault Database be changed to closed for a specified fault 

Basic Course of Events: 

1. A User logs on to the Master Fault Database. 

2. The system displays a list of options. 

3. The User chooses to close a fault and enters the appropriate information. 
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4. The system updates the Master Fault Database. 

5. The User logs out of the database. 

Alternative Paths: In step 5, if the User wants to close another fault record, steps 3 and 4 
are repeated. 

Exception Paths: If the User is not authorized to close a fault record, the system will 
display an error message and go to step 5. 

Trigger: N/A 

Assumptions: The User is an authorized member of the Unit Maintenance crew. 
Preconditions: A fault has been corrected in a vehicle. 

Postconditions: The Master Fault Database has closed the fault record. 

Date: 20-Dec-04 

Table 6 Close Vehicle Fault Use Case 

B. SEQUENCE DIAGRAM 

Figure 12 is a sequence diagram, showing the interaction between the different 
users and the database. Initially, fault data captured in a Vehicle Database will be 
transferred to the Master Fault Database. Once a new record has been created, an 
acknowledgement will be sent back to the Vehicle Database, which will then be reset. 
There is limited space available in the vehicle; as soon as possible, old data must be 
cleared out. At the same time, a Unit Readiness Report will be submitted up the chain of 
command. At some level above the unit, a user in a Senior Command may decide to add 
additional information into the Master Fault Database, such as justification for overriding 
the NMC status of a vehicle. 

Periodically, users at the Major Command level will run reports to perform trend 
analysis and to view a more accurate Operational Readiness within the command. 
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Finally, once unit maintenance personnel have resolved the fault (i.e., replaced the 
hardware, downloaded a new version of software, etc.), the fault record will be closed 
within the Master Fault Database. 



Figure 12 Master Fault Database Sequence Diagram 


C. THE PROPOSED REPORTING PROCESS 

New reports, tracking failures to the LRU level and including the TP #s to further 
isolate the faults, will be added to the current process. Several steps are needed to 
implement this enhancement on the M1A2 Abrams. A similar approach would be used 
for other vehicles, modifying the terminology for the Commander’s display. 

• A vehicle database will be added to the CID LRU. This database will be used 
for collecting the Tank Commander’s comments. It will also gather relevant 
information for each of the warnings: 

• Applicable LRU data (hardware serial number; software version) 

• Troubleshooting Procedure numbers (TP#s), used to describe which test 
procedure failed. 
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• A check will be performed to eliminate duplicate reports. I.e., when BIT 
and/or FIT are run after ST generates a warning, only one set of data will be 
required. Also, if the vehicle is on a multi-day exercise, and the TC decides to 
continue use of the vehicle until the exercise is complete, the same error might 
be identified over several days. Only one occurrence of the fault should be 
captured. 

• The process for undergoing routine scheduled maintenance will be modified 
to include gathering fault-generated data stored in the Vehicle Database. 

• Data from Vehicle Databases will be added to a Master Fault database. This 
master database will be owned and maintained at the Major Command, but 
will be accessible throughout the chain of command. 

• Management, up the chain of command, will incorporate any override or other 
comments into the Master Fault database. 

• Upon request, the major command will generate trend analysis reports. The 
results of this analysis will be forwarded to the appropriate logistics group for 
hardware support and to the Software Life Cycle Maintenance group for 
software and test support. 

• Units below the Major Command can also generate specific reports. These 
reports will be useful when a subordinate unit wants to perform their own 
trend analysis. 

• For all of the above, proper training will be developed and implemented. 

Several steps must be taken to incorporate these databases. 

• A new Vehicle Database will be added to the vehicle’s existing software. The 
physical location of this database will take into consideration available space 
for the new code. Some LRUs have more space available than others. If 
needed, data entered will be passed to the database via the 1553 data bus that 
connects all the major LRUs. 
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• Screens will be developed within the vehicle to allow data entry. The screens 
will be added to the CID with backup capability in the GCDP. 

• When a fault occurs, the TC will enter pertinent data into the Vehicle 
Database. This will include whether the LRU problem is addressed at that 
time or if the problem is overridden. 

• A Master Fault Database for all of the vehicles will be accessible by the local 
maintenance facility. The data in the Vehicle Database for each vehicle will 
be transferred to the Master Fault Database. Data from other Vehicle 
Databases will also be added as the Master Fault Database grows. 

• Faults are identified on a DA Form 2404, using an “X” to identify the 
problem. When the DA Form 2404 has a fault overridden at a level higher 
than the vehicle, a Circle-X is used. As this occurs, the user must enter a 
comment into the Master Fault database as to why the X was overridden. 

• Data from the Master Fault database will be accessible by the Program 
Manager’s office for trend analysis. Assuming a failure trend is identified, 
funding will be requested to address the invalid software/hardware/test 
software. 

• Also dependent upon the trend analysis, an adjustment will be made for the 
number of spares requested/needed. 
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IV. MASTER FAULT DATABASE DESIGN 


A. OBJECT DIAGRAM 

According to Martin Fowler’s book on UML, “An object diagram is a snapshot of 
the objects in a system at a point in time.” (Martin Fowler and Kendall Scott, 2000). The 
object diagram for this system (shown in Figure 13) will consist of the objects described 
in Table 7. This table also shows the relationships (1 to many, many to many, or many to 
1) between the two objects. 



Figure 13 Master Fault Database Object Diagram 


Object 

Relationship 

Object 

Description 

Report 

generalization 


Consists of four (sample report) 

objects: Current Status Report; 

System Version Report; TP # Report; 

and LRU Report. 

User 

generalization 


Consists of three objects: Unit 

Maintenance; Major Command; and 

Senior Command. 
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Report 

*_* 

User 

One or more users can generate one 

or more reports. 

Vehicle 

1-* 

Current Status 

Report 

One or more vehicles will be 

described in the Current Status report. 

Vehicle 

1-1 

Vehicle 

Database 

Data for each (unique) fault is 

collected in that vehicle’s Vehicle 

Database. 

Vehicle 

Database 

1-* 

LRU 

The Vehicle Database contains an 

aggregate of data for the faulty LRU. 

LRU 

1-* 

Trouble¬ 

shooting 

Procedure 

Each LRU contains an aggregate of 

one or more TP #s. 

Vehicle 

Database 

1-* 

System 

Version 

Report 

The System Version Number for each 

vehicle will be used in the System 

Version report. 

LRU 

*_* 

LRU Report 

Data from many LRUs will be used 

in the LRU Report. 

Troubleshooting 

Procedure 

*_* 

TP # Report 

Data from many TP #s will be used in 

the TP # Report. 

Vehicle 

Database 

*-l 

Master Fault 

Database 

One or more vehicles will provide 

data to the Master Fault Database. 

Senior 

Command 

*_* 

Command 

Feedback 

One or more members of the Senior 

Command provide input to the 

Command Feedback object. 
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Command 

Feedback 

*-l 

Master Fault 

Database 

One or more Command Feedback 

sets provide updated data to the 

Master Fault Database for each fault 

in the database. 

Unit 

*_* 

Master Fault 

One or more Unit Maintenance 

Maintenance 


Database 

personnel close one or more faults 




when the faults are resolved. 


Table 7 Object Relationships 


B. DATABASE DESIGN 

1. Database Contents 

The Master Fault Database will contain information collected from the Vehicle 
Databases throughout the command as well as information entered by the various levels 
between the Major Command and the Vehicle level. Table 8 identifies the data, where it 
is derived from, and why it is included in the database. 


Data 

Source 

Comment 

Vehicle System Software 

Version 

From the CID LRU 

(Vehicle Database) 

Used for trend analysis 

LRU ID 

From in the CID LRU 

(Vehicle Database) 

Used for trend analysis 

TP# 

From the CID LRU 

(Vehicle Database) 

Used for trend analysis 

Vehicle ID 

Entered by the TC 

(Vehicle Database) 

Unique value, used as the Primary 

Key. 

Date/Time 

Entered by the TC 

(Vehicle Database) 

Used to determine how long the 

vehicle was NMC. 

Vehicle Operational 

Entered by the TC 

Used for trend analysis, and to 
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Data 

Source 

Comment 

Readiness Index 

Override? 

(Vehicle Database) 

determine actual operational 

readiness. 

Reason for Override 

Entered by the TC 

(Vehicle Database) 

Used for trend analysis, and to 

determine actual operational 

readiness. 

Additional comments 

Entered by the TC 

(Vehicle Database) 

Used by maintenance, for reasons 

for failures, and by logistics 

personnel when ordering spares. 

Vehicle Operational 

Readiness Index Override 

Senior Command 

personnel 

Corresponds to a circle-X. Used to 

determine actual operational 

readiness 

Reason for Override 

Senior Command 

personnel 

Used to determine actual 

operational readiness 

Date/Time of Override 

Senior Command 

personnel 

Used to determine actual 

operational readiness 

Overriding Authority 

Identification 

Senior Command 

personnel 

Used to determine actual 

operational readiness 

Additional Comments 

Senior Command 

personnel 

Used to determine actual 

operational readiness 


Table 8 Master Fault Database Contents 


2. Sample Database Layout 

Records within the Master Fault Database consist of fields containing data 
transferred from the individual Vehicle Databases and additional fields containing data 
from senior commands over the reporting vehicles. In keeping with best practices for 
database design, the data will be divided into several tables to minimize the possibility of 
data corruption, keep the database more manageable, and speed processing. 
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The primary key for each table will be the vehicle ID. Data for a fault will 
initially be transferred from the applicable vehicle. Additional information may be added 
by commands above the vehicle level in the chain of command. Maintenance personnel 
may indicate the fault has been corrected and, depending upon if other faults exist, 
whether the vehicle is now Fully Mission Capable. 

Figure 14 is the Entity Relationship Diagram for the Master Fault Database. 
There may be one or more failures occurring within a vehicle, so the diagram shows 
multiple failures submitted to the Master Fault Database. It also shows personnel in the 
chain of command above the reporting unit may update information on each fault one or 
more times. I.e., information may be submitted by someone at the Company level, and 
also by someone at the Battalion level. 


Vehicle 

M 

Report\ 

M 

Master 

Vehicle 

Database 

M 

Update\ 

M 

Subordinate 

Database 


^xFailure/^ 



^^Failure^^ 


Command 


Figure 14 Entity Relationship - Master Fault Database 


There are two tables containing data for the Master Fault Database, as 
described below. Each field of both Table 9 and Table 10 identify the database Primary 
Key, Field name, type, size, whether it is a required field, and a comment field to explain 
where the data is derived. 

a) Vehicle Data Table 

Table 9 contains data extracted from the Vehicle Database. It allows for 
up to six Troubleshooting Procedure numbers. Each failure within a vehicle will have its 
own record within the database which will allow individual faults to be closed while still 
allowing the vehicle to be classified NMC due to any other outstanding fault records. 
This will also allow a more accurate trend analysis to be performed on individual faults, 
rather than just on vehicles. 
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Key 

Field 

Type 

Size 

Req’d 

Field 

Comments 

P 

Vehicle ID 

A/N 

20 Chars 

Y 

Captured from the CID LRU 

Key types are Primary, 

Secondary, Foreign 


System Version 

A/N 

10 Chars 

Y 

Captured from the CID LRU 


LRU 

A/N 

7 Chars 

Y 

Captured from the CID LRU 


LRU S/W Vers. 

A/N 

7 Chars 

Y 

Captured from the LRU 


LRU H/W Ser. # 

A/N 

7 Chars 

Y 

Entered by User (Tank Crew, 

Maintenance personnel) 


TP# 

N 

5 Chars 

Y 

Captured from the CID LRU 


TP# 

N 

5 Chars 

Y 

Captured from the CID LRU 


TP# 

N 

5 Chars 

Y 

Captured from the CID LRU 


TP# 

N 

5 Chars 

Y 

Captured from the CID LRU 


TP# 

N 

5 Chars 

Y 

Captured from the CID LRU 


TP# 

N 

5 Chars 

Y 

Captured from the CID LRU 


Date/Time 

A/N 

20 Chars 

Y 

Entered by User 


Comment 

A/N 

240 Chars 

Y 

Entered by User 


Table 9 Vehicle Data - Master Fault Database 


b) Change in Status Table 

Table 10 will contain data entered by members of commands senior to the 
faulted vehicle. Data may be entered when overriding a circle-x or just in general to 
explain a failure. It may also be submitted to assist the Major Command when generating 
a trend analysis report. 
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Key 

Field 

Type 

Size 

Req’d 

Field 

Comments 

P 

Vehicle_ID 

A/N 

20 Chars 

Y 

Captured from the Vehicle’s 

Form 2404 


LRU 

A/N 

7 Chars 

Y 

Captured from the Vehicle’s 

Form 2404 


User_Name 

A/N 

20 Chars 

Y 

Entered by User 


UnitJD 

A/N 

20 Chars 

Y 

Entered by User. Name of 

user’s Unit 


ChangeStatus 

A/M 

5 Chars 

O 

Entered by User 


Date/Time 

A/N 

20 Chars 

Y 

Entered by User 


Comment 

A/N 

240 Chars 

Y 

Entered by User 


Table 10 Change in Status - Master Fault Database 


3. Sample Database Reports 

Some of the reports that can be generated from this database are: 

Current Status of Fielded Vehicles - indicates the status of fielded vehicles within 
a specified command. By varying the report date, the command can determine trends. It 
also shows a more accurate Operational Readiness Status. 

Failure Analysis By LRU - indicates if there is a fundamental problem emerging 
for a specified LRU. It will also help ensure the proper numbers of spares are ordered. 

Failure Analysis by Troubleshooting Procedures - this report will isolate failures 
by software or hardware categories. It should be used in conjunction with the Failure 
Analysis by LRU report when ordering spares. For example, if there are hardware issues, 
then replacements are needed. But if the TP #s indicate the issues are software related, 
then updated software should be developed/installed. 
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Failure Analysis by System Versions - this will identify if issues are being 
introduced or resolved by different versions of system releases. This report should be 
used in conjunction with the other failure analysis reports. Failures introduced by new 
versions of hardware or of software need to be analyzed as a whole rather than 
individually. 

For the following sample reports, the Fourth Infantry Division is (arbitrarily) 
used. The reports are as follows: 

a) Current Status of Fielded Vehicles 

This sample report (Figure 15) examines vehicles assigned to the 4 th ID. 
For each NMC vehicle, the vehicle identification is displayed together with the date the 
vehicle became NMC. This information allows the Major Command to take action as 
appropriate: move vehicles from one unit to another, check on status of spares, determine 
if command assistance is required to resolve delays, etc. 


Current Status of Fielded Vehicles 

Command : 

4ID 

1st Brigade. 4th Infantry 

1-66 Armor Bn Total Number of Vehicles On Hand: XXX 

Disabled Vehicles: XXX 

Vehicle ID: XXXXXXXXX Disabled since: XX’XXXX 

3-66 Armor Bn Total Number of Vehicles On Hand: XXX 

Disabled Vehicles: XXX 

Vehicle ID: XXXXXXXXX Disabled since: XX XX XX 
Vehicle ID: XXXXXXXXX Disabled since: XXXXXX 

2nd Brigade, 4th Infantry 

I -67 Armor Bn Total Number of Vehicles On Hand: XXX 

Disabled Vehicles: XXX 

Vehicle ID: XXXXXXXXX Disabled since: XXXXXX 
Vehicle ID: XXXXXXXXX Disabled since: XXXXXX 
Vehicle ID: XXXXXXXXX Disabled since: XX XX XX 

3-67 Armor Bn Total Number of Vehicles On Hand: XXX 

Disabled Vehicles: XXX 

Vehicle ID: XXXXXXXXX Disabled since: XX XXXX 
3rd Brigade. 4th Infantry 

1-6H Armor Bn Total Number of Vehicles On Hand: XXX 

Disabled Vehicles: XXX 

Vehicle ID: XXXXXXXXX Disabled since: XX XX XX 


Figure 15 Sample Current Status of Fielded Vehicles Report 


Dale : 

XXXXXX 
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b) Failure Analysis by LRU 

This sample report (Figure 16) shows the number of LRU failures for each 
vehicle within a Major Command. The report further identifies the individual vehicles 
and shows the number of days the LRU, and in turn, the vehicle, is considered NMC. 


LRU Failure Analysis Report 


Command: 

4ID 



LRU 

CID 

Veh ID 

Vets # 


XXXXXX 

xx.xx 

CITY 

XXXXXX 

xx.xx 


XXXXXX 

xx.xx 


XXXXXX 

xx.xx 

DECU 

XXXXXX 

xx.xx 

DID 

GCDP 

XXXXXX 

xx.xx 

FCEU 

XXXXXX 

xx.xx 

IIEU 

IFCEU 

XXXXXX 

xx.xx 

POS/NAV 

TEU 

XXXXXX 

xx.xx 


Date : 

XXXXXX 


Dale Failed 

Total Days 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 

XXXXXX 

XXX 


Figure 16 Sample LRU Failure Analysis Report 


c) Failure Analysis by Troubleshooting Procedures 
The following sample report (Figure 17) shows the number of failures by 
troubleshooting procedure number for each vehicle within a Major Command. The 
report further identifies related TP # failures and shows, for the specific failure, the date 
the failure occurred. This date is not necessarily the date the vehicle is considered NMC 
since the vehicle may have been rated NMC prior to identifying the failed TP #. I.e., 
there might be a failure in an LRU and, after replacement of the LRU, the FIT identified 
a second LRU problem. 
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Troubleshooting Procedures Failure Analysis Report 


Command: 

4ID 

TP# Veh ID Related TP 

NNN XXXXXX NNN 

NNN XXXXXX 

NNN XXXXXX NNN 

Related TP 
NNN 

NNN 

Related TP 

NNN 

Dale: 

XXXXXX 

Date Failed 

XX XX XX 
XXXX XX 
XXXXXX 


Total failures for TP # NNN: 

NNN 



NNN 

XXXXXX 



XX XX; XX 


Total failures for TP # NNN: 

NNN 



NNN 

XXXXXX 



XXXXXX 

NNN 

XXXXXX NNN 

NNN 

NNN 

XX XX XX 


Total failures for TP # NNN: 

NNN 




Figure 17 Sample TP Failure Report 


d) Failure Analysis by System Versions 

The following sample report (Figure 18) shows failures that occur within a 
vehicle loaded with a specific system drop of software. When compared to the previous 
system drop, it will help to identify which software failures were resolved and which 
were introduced. The latter may occur when a problem is masked due to another 
problem. Once that other problem is resolved, the second problem can be identified and 
resolved. The report will contain entries for all system drops currently fielded. 


System Drop Failure Analysis Report 


: 4ID 


Dale : XXXX XX 


System Version Number: XXX.XXX 


LRU 

NNN 

LRU Vers 
XXX.XXX 
XXXXXX 
XXX.XXX 

Veh ID 
XXXXXX 
XXXXXX 
XXXXXX 

Date Failed 

xx/xx/xx 

xx/xx/xx 

xx/xx/xx 

Total Days 
NNN 
NNN 
NNN 

NNN 

XXXXXX 
XXX .XXX 

XXXXXX 

XXXXXX 

xx/xx/xx 

xx/xx/xx 

NNN 

NNN 

System Version Number: XXX.XXX 



LRU 

NNN 

LRU Vers 
XXXXXX 
XXX.XXX 
XXXXXX 

Veh ID 
XXXXXX 
XXXXXX 
XXXXXX 

Date Failed 
XX/XX/XX 

xx/xx/xx 

xx/xx/xx 

Total Davs 
NNN 
NNN 
NNN 

NNN 

XXXXXX 

XXXXXX 

xx/xx/xx 

NNN 

NNN 

XXXXXX 

XXXXXX 

XXXXXX 

XXXXXX 

xx/xx/xx 

xx/xx/xx 

NNN 

NNN 


Figure 18 Sample Failure Analysis by System Versions 

38 



V. CONCLUSION 


The enhancements proposed in this thesis have been recognized by the Associate 
Director of the Next Generation (NextGen) Software Engineering Center, RDECOM - 
TARDEC for their potential to quantify and resolve low-level software and hardware 
issues. This concept has been submitted as a proposal to become a Department of 
Defense Small Business Innovation Research (SBIR) Program. 

A. VALUE ADDED 

Current reports can identify a vehicle classified as NMC. They cannot further 
identify the LRU that is the cause of the failure. That information might be available 
from examining logistical spare parts orders for the unit but if the wrong LRU is ordered, 
that information is not accurate either. This is somewhat trial and error, and prevents any 
accurate trend analysis from being performed at the major command level. Also, 
historical data for operational readiness is not being maintained. That means the Major 
Command may review the current status of its vehicles, only. 

Having the additional information contained in the Master Fault Database will 
allow statistical trends to be reviewed and will allow commanders to maintain better 
control when ordering replacement LRUs. 

Implementing the new database systems will continue to allow Tank Commanders 
(TCs) and their chain of command to use their best judgment on the operational readiness 
of a vehicle. At the same time, it will enable them to capture important information that 
will improve the state of their repair parts, and ultimately, improve the quality of the 
vehicle’s hardware and application and test software. 

B. CHALLENGES AND OPPORTUNITIES 

1. Safety Critical 

System Safety is always a major concern. From a top-level view, a major 
command expects its units to be combat ready based on the URI for each unit. With 
more detailed reports available, the chain of command can better manage their units in 
preparation for their primary duty — to engage the enemy. 
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From the unit’s viewpoint, resolving problems with faulty LRUs and having 
sufficient numbers of spares available is certainly optimal. 

Addressing reasons for failure, situations where the test might be masking more 
serious problems, will hopefully save crewmembers’ lives. 

2. Difficulty in Gaining Acceptance 

During an interview with a former Tank Commander, SFC Tom Davis, retired, 
SFC Davis said the majority of all faults are documented on a daily basis, on the 
vehicle’s DA Form 2404 (Equipment Inspection and Maintenance Worksheet). It is in 
the best interest of the vehicle’s crew to ensure that the vehicle is fully operational at all 
times. Crewmembers want to see all faults identified and corrected, and an appropriate 
level of spares maintained. It is their livelihood and their lives at stake. The problem of 
overriding the readiness status appears to be at the company and/or battalion level. That 
is where the Circle-X’s are being used. The challenge then is to allow personnel at those 
levels to override the report while getting them to provide explanations. 

This challenge can be addressed by reporting the additional information at the top 
level of the chain of command and then have that report flow back down the chain. Once 
management at the lower levels observes that upper-management is viewing this 
information in the new reports, there will hopefully be a better flow of communication at 
all levels. 

SFC Davis identified a second challenge: crewmembers are constantly busy with 
the current amount of daily requirements. He suggests that there may be resistance to the 
process caused by adding another requirement, to enter the reason for the fault into the 
database, to their workload. Once they see an increase in the attention spent on 
improving the operational readiness of the vehicles, this resistance should be overcome. 

3. Incorporation on Legacy Vehicles 

Because of budget constraints, incorporating this process into legacy systems may 
prove to be the greatest challenge. The Program Executive Office for the legacy vehicle 
will need to add the development of the database software; training for the new system; 
new processes developed for performing trend analysis; etc. into the vehicle’s budget. 
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Since the majority of available funding is already designated, this process will need buy- 
off at all levels. 

4. Incorporation on Future Force Vehicles 

Since there hasn’t been any precedence set for the new vehicle, incorporating 
these new processes should be much easier. The additional features outlined by this 
research as essential for improving the current Unit Readiness Index reporting procedures 
can be incorporated into initial system design. Features such as automatically recording 
data into the vehicle database, and automatically modifying the number of spares 
required by command (based on an automated specific trend analysis to gauge projected 
failures based on the number of current and previously reported failures) can be built in 
and prevent the continuation of the current Operational Readiness reporting problem. 
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